% !TEX root = main.tex

\section{Extend GeKo to Implement Full Core Functionality of the Model Weaver TouchRAM}
\label{sec:extend_geko}

The two main characteristics that distinguish GeKo from other model weavers are \emph{generality} and \emph{extensibility}.

In \sect \ref{sec:adopt_ram}, we mainly illustrated the \emph{generality} feature of GeKo by adopting TouchRAM metamodel 
and conducting a simple modeling and weaving case study. It works well, even without any necessary additional coding, if
the TouchRAM metamodel was just a metamodel of UML class diagrams. But it is not! Besides sub-modules of the metamodel defined
for UML class diagrams, sequence diagrams and state diagrams, the TouchRAM metamodel also defines some modeling
features specific for the TouchRAM model weaver. For example, the \emph{Instantiation} composed in \emph{Aspect} is used
for mapping. While in our case study in \sect \ref{sec:adopt_ram}, we manually defined the mapping in a \emph{Pc2AvMapping} model.
Moreover, there is a variety of modeling and weaving schemas/mechanisms in TouchRAM \cite{Kienzle:2010:ADR:1980562.1980570} 
which are different from those used in GeKo.

Therefore, we will illustrate another major characteristic of GeKo, \emph{extensibility}, in this section, 
\ie adjusting generic modeling and weaving operations of GeKo to be in consistence with the specific ones of TouchRAM, by extending GeKo 
with as little user interference as possible.

\subsection{Extensibility of GeKo}

\begin{figure}[htbp]
	\centering
	\includegraphics[width=0.8\textwidth]{figure/extend_geko/geko_mw_ep}
	\caption{The models, phases and major extension points of the GeKo weaving process}
	\label{fig:geko_mw_ep}
\end{figure}

Figure \ref{fig:geko_mw_ep} depicts the model weaving process of GeKo and possible extension points. Details can be found in \cite{geko.icmt.2013,geko.masterthesis}.
The generic approach used by GeKo may not handle all weaving circumstances for all metamodels in the way desired by the users.
\emph{Extensibility} is achieved by providing users the ability to customize GeKo to obtain a domain-specific weaver.
The customization capability is gained by changing the default weaving behaviors of GeKo through the following extension points:
\begin{itemize}
	\item \textbf{e1}: During the preparatory derivation of relaxed metamodels for \emph{pointcut} and \emph{advice} models, the default generator model can be modified.
				It specifies how Java classes that realize the metaclasses of the metamodel generated.
	\item \textbf{e2}: The process of loading and storing models before and after the actual weaving can be customized through this extension point.
	\item \textbf{e3}: Join-point detection can be completely customized as its result is an ordinary one-to-one mapping from \emph{pointcut} to \emph{base} elements for every join-point.
	\item \textbf{e4}: It is possible to ignore specific properties of metaclasses during join-point detection and model comparison using this extension point.
	\item \textbf{e5}: For the automatic inference of a mapping from \emph{pointcut} elements to \emph{advice} elements the calculation of unique identifiers can be customized.
				These identifiers are used to match \emph{pointcut} elements to \emph{advice} elements.
	\item \textbf{e6}: The introduction of new \emph{base} elements corresponding to \emph{advice} model elements that do not have associated \emph{pointcut} elements can be customized.
	\item \textbf{e7}:  The determination of containment references can be customized for \emph{advice} elements that are not unambiguously contained in another element.
\end{itemize}

Note that the extension point \emph{e1} is not shown in \fig \ref{fig:geko_mw_ep}. 
It is related with the topic of \emph{manipulated metamodels} and will be discussed later in \sect \ref{sec:manipulated_metamodels}.

\subsection{Specific Requirements of TouchRAM for Modeling and Weaving}
Regarding TouchRAM, there is a variety of specific requirements for modeling and weaving in the way desired by the TouchRAM developers.
For instance, see \fig \ref{fig:ram}, the \emph{Aspect} composes optional \emph{Layout} component which stores the coordinates of each model element
for displaying in TouchRAM GUI.
However, GeKo is a generic model weaver that does not provide graphical user interface for modeling but auto-generated eclipse editors.
Fortunately the \emph{Layout} is also optional in \emph{Aspect} according to the metamodel, so we can ignore this component when we extend GeKo.

In this section, we try to find all core modeling and weaving schemas in TouchRAM that are necessary for GeKo to be adapted.
We choose three aspects from RAM CMS case study\footnote{\url{http://www.cs.mcgill.ca/~joerg/SEL/RAM_CMS_Case_Study.html}}, see Appendix \ref{sec:ram_aspects}.
We are not going to explain much details about these aspects in this technical report, since all the relevant information can be found in Section 2 in \cite{Kienzle:2010:ADR:1980562.1980570} .

\subsubsection{Allocatable.}
This is a simple low-level aspect of resource management which provides the functionality of being able to tag an $\mathtt{|Allocatable}$ object
as being allocated by calling $\mathtt{allocate}$ method, see \fig \ref{fig:ram_allocatable}.

Note that the class $\mathtt{|Allocatable}$ marked with a prefix $|$ is a partial class. Any partial class has to be instantiated when the aspect is woven into another aspect.
Similar requirement applies to other partial element, \eg partial states $\mathtt{|Free}$ and $\mathtt{|Busy}$ in this aspect.
The $\mathtt{Binding}$ in the state view indicates that except these partial states, the state $\mathtt{Any}$ is instantiated by default to the element with the same name.
That means when detecting join points, the state $\mathtt{Any}$ can only match the state with the same name in the base model.

\begin{requirement}
\label{rqm:instantiation}
Instantiation: All partial elements of an aspect must be instantiated when this aspect is woven into another. Other remaining elements are instantiated by default to the elements
with the same names respectively.
\end{requirement}

The public interface of a RAM aspect is comprised of all the public operations declared by the classes in the structure view of this aspect.
Regarding $\mathtt{Allocatable}$, the operations $\mathtt{isAllocated}$, $\mathtt{allocate}$ and $\mathtt{deallocate}$ are all publicly accessible.
Note that when the aspect is woven into another aspect, the public interface of this aspect will change to intra-aspect interface in the woven aspect,
\ie they can only be called from other objects that are part of the woven aspect.
Therefore, the visibility of the original public operations is changed to \emph{package}, using the UML package visibility modifier $\sim$.
For example, in the woven aspect $\mathtt{ResourceAllocation}$, see \fig \ref{fig:ram_woven}, the $\mathtt{|Allocatable}$ class is instantiated as $\mathtt{|Resource}$
and its operations are all changed to \emph{package} visibility.

\begin{requirement}
\label{rqm:visibility}
Operation Visibility: The public interface of an aspect must be changed to intra-aspect interface after being woven into another aspect,
i.e. its operations with public visibility should be changed to package visibility.
\end{requirement}


\jackin{This subsection doesn't complete \dots}

\subsection{Extend GeKo}

\begin{figure}[htbp]
	\centering
	\includegraphics[width=0.65\textwidth]{figure/extend_geko/extension_project1}	
	
	\vspace{0.5cm}
	
	\includegraphics[width=0.65\textwidth]{figure/extend_geko/extension_project2}
	\caption{Create a new eclipse plug-in project for extension of GeKo}
	\label{fig:extension_project}
\end{figure}

Before starting the extension work, we first have to create a new \emph{Plug-in} project \emph{lu.uni.geko.ext.ram}, which is stored in the \emph{extensions} folder of the GeKo package
as we recommended before, see \fig \ref{fig:extension_project}.

\subsubsection{Define a new RAM-specific weaving plugin command.}

Open the \emph{plugin.xml} file of the main project of GeKo, \emph{lu.uni.geko}, and go to the \emph{Extensions} tab.
Under the \emph{org.eclipse.ui.commands} section, you can find all the user-defined GeKo interface commands as plugin functions
of eclipse environment.

To add the new command, you need first define your own event handler and the invoking method to process the command.

Make lu.uni.geko.commands package as exported in the manifest of project lu.uni.geko.

Add required plug-ins in the Dependencies tab in the manifest of your created project.
Also add your project to the required plugins in the main project of GeKo.



















